<HTML>
<!-- (c) Copyright 2003, 2004, 2005, 2006, 2007, 2008, 2009 Hewlett-Packard Development Company, LP -->


<HEAD>
<TITLE>Jena Relational Database backend</TITLE>
<link href="../styles/doc.css" rel="stylesheet" type="text/css" />
</HEAD>



<BODY bgcolor="#FFFFFF">



<h1>Jena2 Database Interface - Open Issues</h1>



  <h2><a name="features"></a>Known Bugs</h2>



<dl>
  <dt>Plain Literals vs. XSD String-typed Literals</dt>
  <dd>The RDF recommendation states that if an XSD string-typed literal and a 
  plain literal (no language tag) have the same value (see Literal.getValue()), 
  then they are considered semantically equivalent, i.e., Literal.sameValueAs() 
  returns true.&nbsp; Unfortunately, 
  the database layer does not treat them as equivalent. For example, if a 
  statement  with an xsd string-typed literal for an object is added to a database 
  model, then in a subsequent attempt to list all statements with that value as 
  a plain literal, the original 
  statement (with the typed literal) will not be included in the result set. </dd>
</dl>



<dl>
  <dt>Database Lock</dt>
  <dd>The Jena2 storage subsystem uses a lock (or mutex)&nbsp; internally to implement a 
  critical section for operations that modify the database structure 
  (create/delete tables). The lock is implemented as a database table, i.e., if 
  the table exists in the database, the lock is held. Normally, this lock 
  should be transparent to applications. But if an application has an exception 
  while in a critical section, the database may remain locked for subsequent 
  applications. In this case, a user must manually unlock the database either by 
  calling DriverRDB.unlockDB() or by deleting the table (Jena_Mutex) from the database. </dd>
</dl>



  </BODY>



</HTML>